PASNOT.ARR[UP,DOC]2 - www.SailDart.org

perm filename PASNOT.ARR[UP,DOC]2 blob sn#463019 filedate 1979-08-06 generic text, type C, neo UTF8

COMMENT ⊗ VALID 00013 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 user notes from LOTS community
C00011 00003 * * * * * local user notes (SU-AI) * * * * Last: EJG 6-Jul-79
C00027 00004 History of changes made at LOTS/SAIL ARR 11-jul-79
C00038 00005 ∂24-jun-79 1503 ARR Linkage conventions of the PASCAL/PASSGO/LOTS compilers
C00048 00006 ∂ 8-jul-79 1628 ARR Description of the symbol table data structure
C00053 00007 THE STRUCTURE DESCRIPTOR BLOCK:
C00062 00008 THE IDENTIFIER DESCRIPTOR BLOCK:
C00072 00009 THE DISPLAY ARRAY:
C00074 00010 BIBLIOGRAPHY AND ADDRESSING INFORMATION:
C00076 00011 ∂10-jul-79 1628 ARR Packing Policy
C00081 00012 EXAMPLES:
C00083 00013 ∂20-jul-79 1433 ARR List of Error messages
C00093 ENDMK
C⊗;
user notes from LOTS community
SUBJECT: Pascal compiler observations.

Observations on the Pascal compiler.
(as made by J.JHENN)
1. In @EXECUTE mode the /list option causes the listing to appear
on the line printer. This does not happen in @PASCAL mode.
2. In @PASCAL mode:
If /LIST is specified, LIST FILE must be.
/CREF after the source file causes CROSS REFERENCE, with the
following properties:
A * is printed to which you give the name of the source
file without extension.

The list file (.LST) contains pretty printed listing
and cross reference. The file with the source
name and extension .NEW is a formatted listing.
3. The compiler utilizes PPN, which is no problem, if you use
your own directory.
4. On the run time environment.
Using READ/WRITE. To get TTY (i.e. the teletype), use
TTY as the file name. The default file names are INPUT for READ/READLN,
and OUTPUT for WRITE/WRITELN. MESSAGE is always sent to TTY.
5. When the compiler starts using TTY. It first prints a *,
prompting to fill the input buffer. Note that this occurs
prior to executing other statements (including writes
which are before your reads). No big deal --
just enter CR and then continue as usual.
END OF OBSERVATIONS.
-----------------------------------------------------------------------
A.ARMANDO, 01/12/78
Important details that are easy to forget and will give you problems:
1.- If you forget to put a star (*) after the names of any parameter
file which is going to be used for input, it will be rewritten,
instead of reset. This causes a new,empty version of the file
to be created, and your input is not accessible anymore. The
program will stop with the message INPUT DATA ERROR IN FILE ...
when the first input is attempted.
2.- If you give a device name, such as TTY: to the prompt for the
actual names of the parameter files, no error message will be
sent, but your description will be ignored, and the file name
will be assigned in the same way as if you hit return only.
3.- Remember the way a real number is defined. If your program needs
a real number as input, and at run time it takes a number such
as .3 or 456 or 23., it will report an INPUT DATA ERROR IN FILE ...
They should be typed as 0.3 and 456.0 and 23.0 .
4.- When you are prompted for the file names for files INPUT and
OUTPUT, the only extensions allowed are INP and OUT respectively,
and the name of the file should not exceed six characters. So,
AA.INP is a valid file name for INPUT, but ANY.THING and
LONGNAME.INP are not. For other parameter files, the only res-
triction is size: up to 6 chars for the name, and up to 3 for
the extension.
5.- If you use READLN on TTY, then at runtime you will have to type
two <RETURN> instead of one. The first is taken as the end-of-line
character, and the second indicates end of input, as usual.
-----------------------------------------------------------------------
On the USE of INPUT and OUTPUT as standard files.
(observations by J.JHENN)

The standard files INPUT and OUTPUT are predeclared as TEXTFILES,
by the compiler. They operate in two different ways.

First, if the files INPUT and OUTPUT appear in the file header,
then there names are prompted for. They act as described
in the previous note (by A.ARMANDO).

If the file names INPUT and OUTPUT do not appear in the file
header. Then the files will have the names INPUT.. and OUTPUT..
respectively. Additionally, both files will be reset and the
file OUTPUT.. will be rewritten (i.e. a new creation if it
already exists - otherwise a new file). This is equivalent
to putting INPUT*,OUTPUT in the file header and replying to the prompt
INPUT= input..
OUTPUT= output..
__________________________________________________________________
A.ARMANDO 01/17/78
Another warning: INPUT and OUTPUT are predeclared for you by
PASCAL, so they SHOULD NOT EVER be included by you in a VAR
declaration. If you declare them, for some unknown reason they
end up being declared to the system as BINARY, and you will not
be able to read characters from INPUT.
----------------------------------------------------------------------
* * * * * local user notes (SU-AI) * * * * Last: EJG 6-Jul-79

∂ 6-Jul-79 1326 EJG Loader halt at 2704 (from GRIPES.TXT[2,2])
∂15-Feb-79 JRQ 16-Feb-79 EJG running PASCAL jobs
Whenever I try to execute a PASCAL job, the loader comes up
with a message "Halt at user 2704" which seems to be
related to the absence/incorrectness of the PASCAL library.
The same program runs at SUMEX (in fact the only library
functions it uses are MIN SQRT and RANDOM). Any suggestions?
JRQ

EJG - The halt at 2704 is a bugtrap in the LOADER, apparently reflecting
the fact that the SAIL version of the LOADER cannot handle some of the
more modern relocatable file block types, which are used in the PASCAL
scientific subroutine library.

Until this bug/lack of feature in the LOADER is fixed (which may be a
while), you have to use LINK-10 to load any .REL file which uses the
PASCAL scientific subroutines. This may be done by using the /LINK switch
in COMPILE, LOAD, or EXECUTE commands. For further information on using
LINK-10, see the monitor command manual and/or LINK.JFR[S,DOC].

Using LINK-10 like this has another questionable "feature," namely that
once the core image is set up, just before exiting or tranferring to
the user's start address, the linker will occasionally get an ill
mem ref (at loc 10?). However, my experience has been that the core
image is indeed O.K., so you can simply say START or SSAVE or whatever
you were planning on doing with that core image.

∂ 5-jul-79 0849 ARR LOTS version is back up

The LOTS version is back up again. When it was released on monday, some
people had problems, so it was taken away and checked. The three problems
that were rported have been corrected:
1. The runtime library was missing one entry point, for a routine
that checks for nil or undefined pointers.
2. The default memory size is set to the maximum at LOTS, where the
virtual memory is paged, while here, where it is only two chunks, that
is bad memory management.
3. Due to a typo, the compiler was generating wrong code, that would
destroy the stack pointer whenever you would do an assignment to an
element of an array in whose type the range of the subscript had an
upper bound of exactly 15.

One extra feature of the new version is that now, when you cal it directly,
it will no complain if you don't close the bracket when giving it the name
of a file in another area.
Armando.

∂ 2-jul-79 1146 ARR LOTS version is up here

The most recent LOTS version of the PASCAL compiler has been brought up to
SAIL, with some improvements. The old one is still available by .R PASOLD
.R OPASC still exists also, although I don't really know why we keep it.
PASCAL is not officially supported yet, although your gripes will get an
answer.

If you DON'T know PASCAL/LOTS, you can see all the changes in page 4 of this
file. Main additions are the /PROFILE switch and the string package.

If you know PASCAL/LOTS, you will notice that PASCAL/SAIL:

0. accepts the switch (LOG)(compiler option (*$G*) ) : using it produces
a file FOO.LOG (FOO.PAS is your source) containing a copy of your
terminal error messages. to use it, you say
.EXE FOO(LOG)
1. keeps the line/page count correctly matched with E.
2. will give you page numbers as it goes compiling, and for long pages,
it will give the line count every 500 lines.
3. In error messages, it will give you both the line/page number and the
name of the procedure you are in.
4. When using input files from TTY:, now you get a silly prompt that tells
you what to do, instead of just entering LINE mode.
5. If you use the predefined procedure ASKFILENAME, now it needs one more
argument. READ PASMAN/42p for details.
6. When giving filenames at runtime, you can ommit the right bracket, just
like everywhere in the system.

The documentation (PASHLP, PASMAN, PASCAL) has been updated accordingly.

*** YOUR OPINION, PLEASE ***

PASSGO and PCROSS are candidates for implementation here. Please give your
opinion on their usefulness to ARR

*** FUTURE ***

In the (more or less) near future, the next additions are planned:
(besides fixing any bugs that can be fixed)

1. /PROFILE will give procedure timing, besides statement counting
2. Some sort of conditional compilation, based in the OPTIONS mechanism
that is, comments that start with $).
3. A cross referencer that does not do 'prettyprinting', derived from PCROSS
4. A prettyprinter that does not lose as mucha s PCROSS (Does anybody have
FORMAT (PUG notes #13) online?)
5. More frienly interactive I/O routines.
6. Larger sets, and upper and lower case in type CHAR

The next misfeatures are still supported, but they will be suppressed soon,
unless strong opposition is shown:

The current meaning of the characters " and # (What? you don't know their
meaning? Good! don't ask.)

Comments, complaints, suggestions, etc. to ARR

If you know of someone who is willing to do some work in MACRO for the user
community, let me know.

***********

∂22-jun-79 1825 ARR Explanation of the problems with TTY: files

There is one bug, that by virtue of its being documented here will from now
on be called a feature, that relates the use of the device TTY: in files that
are parameters of PASCAL programs.
The operating system in this computer (SAIL) will not allow two channels to
be directed to the terminal for input simultaneously; same thing with output.
The effects are several fold:
1. When you are using the debug ( the (*$d+*) option ) and you declare
one of your parameter files as tty:foo, then you will never
be able to execute your program: when the debuger should
prompt you with 'DEBUG: PELOS" and then put the "$", it will
send them into the infinity, and your terminal will enter
LINE mode, and you cannot get out of it.
2. If you declare two of your parameter files as TTY:Foo and TTY:F2,
the same effect will be reached when you give the second one.
3. If you use in your program the pascal-defined file TTY, and you
declare one of your program parameters as TTY:FOO, the former
will be lost. An attempt to read from TTY will put you in
LINE mode; anything WRITtEn to TTY will float in limbo.
EJG was nice enough to trace this bug from the symptoms to the origin. He and
I discussed what it would involve to fix it. We should either:
(a) change this Tops-10 restriction (not our bag, I guess) or
(b) Get the runtimes (written in MACRO) to be smart enough to look around and
find out if some other channel is already tied to TTY: on the same
mode, and if so, find out its (PASCAL-created) file descriptor block
and kludge things for both files to go to the same channel, and through
the same file buffers. Not an easy thing to do for a PASCAL hacker.
We would need an assembler-level hacker.

Open questions:
1. Any volunteers? If so, please contact me. (ARR).
2. Do you know if this restriction is standard in other DEC-10 sites?
if so, please let me (ARR) know. Thanks.

********

∂05-Oct-78 0307 EJG Kluge to allow large one-segment PASCAL programs

PDP10 PASCAL is quite strongly oriented towards using two-segment core
images, with the lower containing mostly variable information and the
upper containing pure code. However, for address space reasons (at least)
it occasionally becomes desirable to run a PASCAL program in one segment,
to let it use all of one address space (2↑18 words).

This note describes a kluge which allows for this in a somewhat limited
and very unclean way. Perhaps it will be obsoleted someday when someone
figures out how to "do it right," e.g. implements a switch similar to
SAIL's "/NOSAISEG".

First, the PASCAL DEBUG package makes a number of assumptions about
absolute locations of some data, so single-segment programs cannot be run
with DEBUG (*$D+*) turned on (until such dependencies are removed).
However, note that this does not exclude running with runtime tests
(*$T+*) turned on (as is the default). The procedure outlined below will
load the PASCAL program with DDT, which can be used as an assembly-level
debugger if this is any help.

To start building the single-segment core image, make sure that no (*$D+*)
options appear in the source program which would invoke PASCAL DEBUG.
Also, chances are that you want to specify some large amount of runcore
for the program (or else you wouldn't be bothering with this procedure),
such as (*$R240*). Then create the relocatable object file with a command
such as:
.COMPILE FOOBAR
...which compiles FOOBAR.PAS into FOOBAR.REL.

Next use LINK to create the forced single-segment core image (containing
DDT), as follows:
.R LINK
*/SEGMENT:LOW=FOOBAR
*/SEGMENT:LOW/SYSLIB=
*/TEST:DDT=
*/G=
(sometimes LINK exits with "Ill mem ref at user 10", but the core image it
builds seems to be complete enough to work anyway...sigh)

Now, before saving (or running) the core image, it is necessary to do a
small amount of patching with DDT, as follows (here things the user types
will be enclosed in braces "{}"):
.{DDT<return>}
FOOBAR$: {jobsa[} <some numbers>{<tab>}
<some instruction>{<return>}
{.+36/} <some instruction>
...it may now be necessary to search about a bit with {<line feed>} and/or
{↑} (up arrow) to find the right three instructions, but once you find
them you proceed like this:
40641/ HRRZM 16,.JBDA+3 {JFCL<line feed>}
40642/ SKIPE .JBDA+6 {JFCL<line feed>}
40643/ XCT .JBDA+6 {JFCL<line feed>}
40644/ JRST 40357 {<CALL> or <CTRL-C>}

The single segment core image should now be set up, ready to be saved
with the SAVE command (not SSAVE), or run with the START command. Believe
it or not this mess really does tend to work! Good luck...
History of changes made at LOTS/SAIL ARR 11-jul-79

∂ changes made to PASCAL/PASSGO on 11-jul-79: ARR

1. Error messages show two lines: the one in error an the previous one.
2. PCREF is up: it is the cross-referencing part of PCROSS/LOTS.
.READ PCREF for details.
3. The /PROFILE switch has been implemented properly. It produces
a listing with statement count information, similar to that of the
ALGOLW compilers. To use it:

.EXE MYPROG(PROFILE)

... after your program has run :
.R PCREF

The file MYPROG.KNT contains intermediate information. PCREF will
leave it empty after processing it. Your listing is in MYPROG.LST.
None of the other PCREF options is given to you by default, but
you can get them there by giving them to the compiler together
with the (PROFILE) switch, e.g. .EXE MYPROG(PROFILE,CROSS:15).

∂ changes made to PASCAL/PASSGO on 1-jul-79: ARR

1. Now it can see page marks in files with no SOS lines. All PASCAL
programs can also. See COPY.PAS[PAS,SYS] for a sample.
2. In compile-time error messages, it will give both the line/page
number and the name of the procedure in which it occured.
3. A bug was fixed: if you would have an array with more than
377777B elements (max half-word positive integer), it would give you
a runtime error ARRAY SUBSCRIPT OUT OF BOUNDS when your subscript
would go over that value.
4. A new switch was added, to provide for a hardcopy of the messages
sent to the TTY, without getting a listing of all the source.
use the switch (LOG), compiler option (*$G+*). The log file will be
called XXXXXX.LOG , where XXXXXX.PAS is your source file.
NOTICE that the switch is not /LOG, but (LOG). This is because SNAIL
does not know this switch. So, to compile FOO.PAS and get a logfile,
say:
.COMP FOO(LOG)
5. When a PASCAL program prompts for file names at runtime, you can
ommit the right bracket in the PPN, just like everywhere else in the
system.

∂ changes made to PASCAL/PASSGO on 31-may=79: ARR

1. MIN and MAX require at least two parameters. one parameter will
produce a compilation error message.
2. the switches [NO]TTY and [NO]OUTPUT were added, to tell the
compiler that external/fortran procedures will [will not] use
the input file TTY and the output file OUTPUT. (this avoids the
silly message prompt, and your having an empty OUTPUT file always)
the compiler options are (*$Y-,O-*). default is ON in both.
3. A bug in MESSAGE was fixed, by which it would fail when trying
to write a scalar as the last thing.

∂ changes made to PASCAL/PASSGO on 27-mar-79 ARR

(*NOTE: the interfase of /PROFILE with the system has not been
tested yet. ARR 2-jul-79*)
1. The switch /PROFILE was added. If you EXECUTE a program with that
switch, PCROSS will be started after your program, and it will
show on the left margin the number of times that each basic block
was executed. Only the first statement of each basic block will
have a count.
To get a profile of MYPROG.PAS :
@EXECUTE MYPROG/PROFILE
Once your program and PCROSS have run, MYPROG.CRL will contain
statement counts on the left margin, after the line number.
the compiler option to use in the source is (*$C+*).
2. the procedure SETRAN(i: integer) is now supported. It allows to reset
the seed for the function RANDOM(dummy:real). For details on how
they work, see the FORTRAN manual.
3. Files with no line numbers are treated in a nicer way now. The compiler
doesn't see the page marks yet (any volunteers to fix that one?)
(*this one improved. ARR 1-jul-79*)
but now:
a. In an error message, it gives you the procedure name
instead of the page number.
b. The line increment was changed to one.
c. It produces a file XXXXXX.PRC, where XXXXXX is the name
of your source file, that gives, for each procedure,
the name, and the line numbers for the header line,
the BEGIN statement and the END statement. This can help
you ubicate the errors and also use the debugger.
4. Fixing small bugs and making cosmetic changes.

Things that are being done now:
A. Conversion to native DEC-20 mode. This will speed things up
between a 20 and a 50%.
B. Improving (first af all, fixing) the debugger.
C. /PROFILE will eventually give also timing counts for each
procedure.

Comments, complains, suggestions, etc. to A.ARMANDO at LOTS,
CSL.ARMANDO at SCORE, ARR at SAIL.

∂ changes made to PASCAL/PASSGO on nov-1-78: ARR

+ A String Manipulation Package was added. See the documentation
on DOC:PASCAL.STRINGS
+ The file OUTPUT will not be created if you don't use it.
+ There was a bug by which, if you would declare any file in the
program header (as a program parameter), INPUT and OUTPUT would
not be open unless they were also in the header. It was fixed.
+ The number of errors detected was not being counted right. Now
it is.

∂ changes made to PASCAL during summer 1978: ARR

1. Bugs that were fixed:
+ It would take '\' as an end of comment.
+ If your program had a lot of comments following each other
(not one big comment, but open-close-open.... comment)
it would run out of memory space.(it would scan recursively)
+ when using the CREF switch, it was not passing the file names
to PCROSS.
+ to assign a parameter file to TTY: you would have to type
TTY:FOO instead of only TTY:
+ The procedures DATE and TIME were returning empties.
+ It would try to LOAD the object file even if there were errors.
+ Sometimes, it would produce, without aparent reason, the message:
STACK OVERRUNS HEAP: RETRY WITH MORE CORE

2. Things changed in the compiler:
+ Now, the PASCAL programs will detect pointers that are nil or
undefined, and isue the appropriate error message.
+ Now the bell will sound at the end only if there are errors.
+ It works fine with all the compile-class commands. Particularly,
if you say @DEBUG MYPROG.PAS, it will invoke the PASCAL debuger
properly (If you say @EXEC MYPROG.PAS/DEBUG, it will not work
yet, though).
+ When calling it directly, you can default (by <cr>) the object
and list file names. They will be MYPROG.REL and MYPROG.LST,
respectively. Or you can default any of the file extensions.
they will be .REL, .LST and .PAS, respectively.
3. NEW COMPILER: PASSGO!
+ An INCORE version, called PASSGO, was created. It is much faster
and it is compatible with PASCAL in everything except external
procedures. The extension for PASSGO programs is PGO.
∂24-jun-79 1503 ARR Linkage conventions of the PASCAL/PASSGO/LOTS compilers

LINKAGE CONVENTIONS OF THE PASCAL AND PASSGO COMPILERS FOR DEC-System10
AND DEC-System20, HAMBURG AND LOTS VERSIONS
Version 1.0

Armando R. Rodriguez
6-aug-79

Abstract:
A semiformal description of the memory and ACregister mapping mechanism
is given, together with a description of the linkage convention and the
frame setup sequence, for code generated by the DEC10-DEC20 PASCAL
compilers. Comments are added in some places, to clarify things for
the reader who plans to write a routine in assembly language, and
call it from PASCAL programs.

Acknowledgements:
Thanks to Polle Zellweger and Dan Halbert, who pointed out flaws in the
first draft, and helped getting ideas straight for this one.

Notation:
a) All the references to ACregisters are octal numbers. The letter B
after the number means octal.
b) For relative addresses, assembly language notation is used:
1(17B) means (contents of right half of 17B) plus one.

0. ACregister mapping:
ACregister 17B points to the top of the stack.
ACregister 16B points to the bottom of the current stack frame
(the top of the stack for the caller, plus one)
ACregister 15B points to the 'top' of the heap (the heap grows
down from the top of the low segment towards the stack.)
ACregisters 7 to 14B are used as an upside-down stack to keep
WITH pointers (That is, it grows from 14B towards 7).
Inside PASCAL code, the expression evaluation stack grows from
ACregister 2 towards the WITH stack. (if it runs out of
registers, PASCAL gives a compile time error. It does
stack height reduction, so this rarely happens).
ACregisters 2 to 6 will participate in the parameter passing.
(The value 6 is the default value for the switch /REGISTER
or compiler option (*$Xn*). See the manual[1] for details)
If there is a nonempty expression evaluation stack (when
calling a function to evaluate a parameter, only) then
it is saved and restored by the caller.
ACregisters 0 and 1 are never used by PASCAL-generated code:
they are kept free, for the use of the runtime routines. If
you are writting an assembly-language routine, and you don't
call any runtime library routine, you are free to use them.

1. But, where is the display kept?
The display is not kept as an entity. The dynamic link is carried
around by the left half of ACregister 16B, and deposited in the last
word of the caller's frame, in the left half also. This word was
allocated by the caller for that specific purpose. So, to get the
base of the frame for the caller of your caller (two levels), you
use the left half of -1(16B), put it in ACregister X, and then use
the left half of -1(X).

2. Things done by the caller on call:
a) Save any live registers in the range 2 to 6, in temporary space
in its own area, and from the range 14B down to 7, in the
location of the corresponding pointer variable.
b) Pass the parameters (see 3 below).
c) Isue a PUSHJ 17B,<callee> to call.

3. Passing parameters:
a) ACregisters 2 to 6 are used for the first parameters.
b) VAR parameters:
The address is passed. The callee will access them indirectly.
c) Non-VAR parameters, one- and two-word long:
The value is passed in the ACregisters. If it is a two-word,
and the first word falls in ACregister 6, it is put there, and
the second word goes to its target place BEYOND the stack.
d) Non-VAR parameters, larger than two words:
The address is passed in an ACregister.
e) When the six ACregisters have been used up:
what would have been passed through the ACregister is
put directly in its place in memory BEYOND the top of the stack.

4. Memory mapping of the callee's area:
starting in the base address (contents of 16B when in your area,
contents of 17B plus 1, when beyond the stack):
For procedures: 1(base) has the first parameter. Parameters are
assigned memory in the order in which they were declared.
For functions: 1(base) is where the returned value will be put.
2(base) has the first parameter. Everything else is the same.
local variables come after the parameters, almost in the order of
declaration. (a group of variables declared by an id-list
is allocated in reverse order).
Any temporary save areas are allocated after the local variables.
They are used as a compile-time-assigned stack, and the
highest level is allocated.
An extra word is allocated for the dynamic link.

5. First things done by the callee:
a) Reorganize ACregisters 16B and 17B to point to its own frame.
b) Update the dynamic link by moving around halfs between 17B,
16B and -1(16B).
b) Copy the parameters from the ACregisters into their places in memory.
+ Value (Non-VAR) parameters which are longer than two
words: Take the address from the ACregister, or from the
first word in its memory location (if it is an overflow
parameter), and do a BLT (Block transfer).
+ VAR parameters, and Non-VAR which are one or two words:
If they are in ACregisters, copy them into their place in
memory. If not, do nothing.

6. Registers that the callee can use:
All of registers 2 to 14B. Any of them that were alive were saved by the
caller. If you don't call any of the runtime library routines, you can
use registers 0 and 1 also.

7. Last things done by the callee:
a) Put back in place the left halfs of ACregisters 17 (PUSHJ count)
and 16B (Dynamic link).
b) Isue a POPJ 17B to go back.
c) Nothing else. Even if it is a function, the result was put in its
place if and when an assignment was made to the function
identifier. (its place is 1(16B), or 1(17B) if you did not
build your own frame).

8. Things done by the caller on return:
a) Reconstruct its own frame.
b) If it saved ACregisters in memory, bring them back to place.
b) If the callee was a function, pick up the result from 2(17),
and put it in an ACregister (the current top of the expression
evaluation stack).

BIBLIOGRAPHY:

[1] Rodriguez, Armando: Pascal and Passgo at LOTS, adapted from
Pascal for the DECsystem-20, by E. Kisicki and H.H.Nagel.
Available on-line at LOTS and SCORE in DOC:PASCAL.MAN
accessible at SU-AI by .READ PASMAN

∂ 8-jul-79 1628 ARR Description of the symbol table data structure

DESCRIPTION OF THE DATA STRUCTURE THAT MAINTAINS THE SYMBOL TABLE IN THE
PASCAL AND PASSGO COMPILERS FOR DEC-10,DEC-20, LOTS AND HAMBURG VERSIONS.

Armando R. Rodriguez.
8-jul-79

ABSTRACT - INTRODUCTION

The symbol table is formed with five basic elements: Constant descriptor
Blocks, Value descriptor blocks, Identifier Descriptor Blocks (CTP↑),
Structure (Type, mainly) descriptor Blocks (STP↑) and a main frame, that
keeps the symbol table and implements the scoping mechanism (DISPLAY).
The first two ones are extremely simple, and will not be described in this
document. The other three ones contain most of the useful imformation.
A brief global description of each record is made, and an explanation of
the meaning and usage of each field follows, retainng the CASEing structure
of the record. An excception is made in that the dummy fields are all des-
cribed together. When it seems appropriate, an explanation is given on the
meaning and purpose of each of the possible values of a given field.
The approach is not purely informal, but it is not absolutely rigurous.
The intention is to be rigurous enough to prevent ambiguities.
Comments and criticisms on this draft are welcome, encouraged and appreciated.
(See address information in the last page).

EXPLANATION OF SOME TERMS:

CHAIN: The linker provides a feature that this compiler takes good advantage
of: When an address is needed that is not known, a "patchback request"
can be issued (Internalrequest, ITEM_10 is used for GOTOs and calls to FORWARD
procedures, and a Symbols, ITEM_2, for external procedure and runtime calls).
The request provides the address of the instruction that needs it and is
situated in the highest position in memory. There, instead of the address that
will be patched back, the address of the next highest requestor is kept, so
forming a backwards (top-down?) chain of requestors of the same address. The
last element of the chain contains a zero (0). The current top of that chain
is kept in field GOTO_CHAIN for labels, LINKCHAIN for Procs/Funcs, and ...
VECTORCHAIN for scalars. Since the Linker does not participate in PASSGO runs,
PASSGO does tha backpatching itself with the procedure WALKCHAIN, instead of
the request made by PASCAL using the procedure WRITE_PAIR.

BASE TYPE and HOST TYPE: This is the terminology used in the proposed ISO
standard for PASCAL. Base type refers to the type of
the elements of a set, and Host type refers to the original type from which a
closed interval defines a subrange type.

LEVEL AND SCOPE: An identifier defined at a given level is assigned that level.
Its scope is all levels with a numerical value higher than
its own, that are not in the scope of another identifier with the same name and
a level with a numerical value higher than its own. Level 0 is assigned to pre-
declared objects, level 1 to global objects (declared in the main block) and
levels 2 and up to the local objects inside procedures and functions.

THE STRUCTURE DESCRIPTOR BLOCK:

Its main purpose is to describe a type by its structure. No naming is
managed directly by this record, although it will point to identifier
descriptors in the case of declared scalars and fields of records.
The values of SCALKIND: TAGFWITHID, TAGFWITHOUTID and VARIANT are used to
describe parts of a record structure. All the other values have obvious
meanings. (POWER stands for powerset).

STP: Pointer to a STRUCTURE descriptor record
STRUCTURE: Structure descriptor record.
DB0, DB1, DB2, DB3, DB4, DB5, DB6, DB7, DB9: Dummy fields used to get
better addressing in the other fields.
SELFSTP: Used to build the debugger tables: a copy of this record, with
the pointer values changed to be meaningful at runtime.
SIZE: Memory space needed by a variable of this type, in words.
NOCODE: Flag set while dumping the debugging information, to prevent
from dumping a record twice.
BITSIZE: Memory space needed, in bits, if this type is used to build a
packed structure. (if SIZE > 1 word, BITSIZE = 1 word).

FORM: Flag to distinguish the different structures. The names are obvious,
and briefly described below.

SCALAR: A simple type, except for subranges.
SCALKIND: STANDARD: Integer, Real or ASCII (CHAR is a subrange)
DECLARED: Named scalars, including booleans.
FCONST: Pointer to the IDENTIFIER descriptor for the first member
of this type. They will be chained by their NEXT field.
VECTORADDR: Address of the string constant that contains all the
names of the elements, ordered from value zero.
VECTORCHAIN: Top of the chain of references to VECTORADDR.
See explanation on chains above.
DIMENSION: Ord(Last(this type)): The maximum value that is defined
by a name in this type. It is also the number of
elements minus one.
NEXTSCALAR: All type descriptors that describe declared (named)
scalars are chained through this field, to simplify
the dump of their name strings in WRITE_MACHINE_CODE
REQUEST: Flag that sets true if any formatted I/O (read/write) is
done on this type, or it defines a parameter to an
external procedure. Used to decide whether to dump
the string of names for runtime use.
TLEV: The scoping level at which the type was defined.

SUBRANGE: Subrange type. Includes CHAR.
RANGETYPE: Pointer to the STRUCTURE descriptor of the Host type.
VMIN, VMAX: Minimum and maximum values of the closed range that
defines the subrange. (Subranges of real are suppor-
ted).

POINTER: Pointer Type.
ELTYPE: Pointer to the STRUCTURE descriptor of the type this type
will point to.

POWER: Set type.
ELSET: Pointer to the STRUCTURE descriptor of the Base type.

ARRAYS: Array type.
ARRAYPF: "Packed Flag": true if the elements of this array are packed
ARRAYBPADDR: Address of a word in data area reserved for a byte pointer
used for addressing elements of this array.
AELTYPE: Pointer to the STRUCTURE descriptor of the type of the element
of this array.
INXTYPE: Pointer to the STRUCTURE descriptor of the type of the subs-
cript of this array.

RECORDS: Record type.
RECORDPF: "Packed Flag".
FSTFLD: Pointer to the IDENTIFIER descriptor of the first field of the
non-variant part of this record. They will be chained through
the NEXT field.
RECVAR: Pointer to a STRUCTURE descriptor of FORM TAGFWITHID or ...
TAGFWITHOUTID, from which the description of the variant part
hangs. NIL if no variant part.

FILES: File type.
FILETYPE: Pointer to the STRUCTURE descriptor of the type of the
elements that form the sequence in this file, or, in other
words, the type of the so-called file_buffer_variable.
FILEFORM: Binary value used by runtimes to distinguish a file that will
be used with formatted I/O (Text_file) from one that needs
Standard I/O (data_file).
FILEMODE: Binary value used by the runtimes to distinguish a file that
has byte-long elements (TEXT, PACKED FILE OF ASCII) from
one that has n-word-long elements (all other files).

TAGFWITHID: A tag field that uses physical memory space: points to
the alterantive VARIANT part descriptors.
TAGFWITHOUTID: Same, for a tag field that does not use memory space.
FSTVAR: Pointer to the STRUCTURE descriptor for one of the alternative
VARIANT parts of this record at this (casing) level. Notice
that the lexical level remains the same as long as the type
of a field is not a record itself, so nested CASEs are still
at the same level. The other VARIANT alternatives will be
chained through the NXTVAR field.
TAGFIELDP: Pointer to the IDENTIFIER descriptor of a TAGFWITHID.
TAGFIELDTYPE: Pointer to the STRUCTURE descriptor of a TAGFWITHOUTID.

VARIANT: The structure that is 'active' in the variant part of a record,
when the corresponding tag field has some given value.
NXTVAR: Pointer to the STRUCTURE descriptor of the VARIANT part for
some other value of the tag field.
SUBVAR: Pointer to the STRUCTURE descriptor of a TAGFWITHID or of a
TAGFWITHOUTID that describes a variant part contained in this
variant part, if any. (e.g., in this record type, STRUCTURE,
the VARIANT descriptor for FORM = SCALAR points through SUBVAR
to the TAGFWITHID descriptor for SCALKIND).
FIRSTFIELD: Pointer to the IDENTIFIER descriptor of the first field of
this variant part.
VARVAL: Value that the tag field should have for this VARIANT to be
'active'. (valid/current).

THE IDENTIFIER DESCRIPTOR BLOCK:

Its main purpose is to describe the meaning and properties of an identifier.
No structural information is reflected directly in this record, except for the
fact that declared scalars, parameter lists and fields are described by a chain
of identifier descriptors. The names used in the main variant part have obvious
meanings.

CTP: Pointer to an IDENTIFIER descriptor record.

IDENTIFIER: Identifier descriptor record.
VDUMMY1, VDUMMY2, HDUMMY, PDUMMY: Dummy fields used to get better addressing
in the rest of the fields.
NAME: Of the identifier.
LLINK, RLINK: To keep the identifiers of each level (scope) organized in a
binary search tree, by NAME.
IDTYPE: Pointer to the STRUCTURE descriptor of the type of this constant,
variable, field or function. NIL otherwise.
NEXT: Used to form chains of identifiers. Depending on KLASS, it points to:
in KONST: (when it is a member of a declared type): the member of the
type with the internal value immediately lower than this one.
in VARS: (When they describe a parameter of a procedure):
The next parameter.
in FIELD: Next field of this static or variant part of this record type.
in PROC and FUNC: (When they are ACTUAL): The first parameter.
in LABELS: Next label that was declared at this same scope level.
(This chains are complementary. All identifiers hang from RLINK, LLINK).
SELFCTP: Used to build the debugger tables: a copy of this record, with the
pointer values changed to be meaningful at runtime.
NOCODE: Flag set while dumping the debugging information, to prevent from
dumping a record twice.

KLASS: Flag to distinguish the different kinds of identifiers. The names are
obvious, and are briefly explained below.

KONST: A constant. (either a name that defines a number, as declared in the
CONST part of a program, or an element of a declared scalar type)
VALUES: Its numerical value.

VARS: A variable. (either a parameter or a local variable).
VKIND: ACTUAL: Local variable or value parameter.
FORMAL: VAR parameter.
VLEV: The level (scope) at which it was declared.
CHANNEL: For variables that are files, the actual hardware channel number
that will be requested for it at runtime.
VADDR: Address of the place in memory that was assigned to it. For local
variables and parameters, it is relative to the base of the stack
frame (pointed to by ACregister 16B). [2]

FIELD: A field of a record (either in a static or a variant part.)
PACKF: "Packed" flag: (it should be called ALIGNMENT flag): information
on the location of its starting address: either at a word boun-
dary, or at a half-word boundary, or at some bit position inside
the word, which requires a byte pointer to access it.
NOTPACK,HWORDR,HWORDL: FLDADDR: Address of the field, relative to the
address of the record.
PACKK: FLDBYTE: a descriptor of the bytepointer used to reach this field.

PROC, FUNC: A procedure or function (either the proc/func itself, or an
EXTERN or FORWARD reference, or a proc/func declared as a
parameter).
PFDECLKIND: Distinction between standard and declared. (NOTE: This is
not the PASCAL language meaning of standard and declared/prede-
clared.)
STANDARD: it needs special parsing, either because it is decompo-
sed into calls to different runtimes(READ/WRITE) or because it
takes non-standard parameter lists (GET,PUT,BREAK,...) or
because it is compiled inline (PACK/UNPACK, ABS,...).
KEY: subscript for its name in NA (STDFUNC or STDPROC)
DECLARED: it has no special treatment, so a call to it will be
treated by the CALL_NON_STANDARD procedure.
PFLEV: level at which it was declared.
PARLISTSIZE: amount of memory space needed in the stack frame for
the parameters.
PFADDR: Address of the entry point, for a local procedure.
HIGHEST_REGISTER: Highest register used for parameter passing.
Usually 6. See the description of the /REGISTER:n switch, or
(*$Xn*) option [1]. See also [2]
PFKIND: flag to distinguish parameter procedures.
ACTUAL: Not a parameter procedure.
FORWDECL: Flag. True if it was declared forward and the
body has not been compiled yet.
EXTERNDECL: True if it was declared external or if it is a
predeclared procedure from the runtime library.
ACTIVATED: True while parsing inside the scope of this fun-
ction, so that its appearence in the left side
of an assignment is legal.
PFCHAIN: To keep three chains of IDENTIFIER descriptors:
one for local, one for forward references, and
one for external references, for ?, for Inter-
nal requests, and for symbol requests, respec-
tively.
LANGUAGE: Either PASCALSY or FORTRANSY, to apply the diffe-
rent linkage conventions.
TESTFWDPTR: Chain of forward procedures declared at this
scope. For test on unsatisfied forward decla-
rations.
EXTERNALNAME: To be used in the Symbols request to the
Linker.

LINKCHAIN: Top of the chain of references (calls) to this
procedure/function. See explanation on chains
above.
FORMAL: A parameter procedure/function.
FPARAM: Poiner to the IDENTIFIER descriptor of the first
parameter to this procedure. Note that these
descriptors have no name, and are not inserted
in the binary tree. [1]. (In actual procedures/
functions, it is kept in NEXT, but here NEXT
points to the next of the parameterlist in which
this procedure is a member.)

LABELS: A Declared Label.
SCOPE: Level at which it was declared, which defines its scope.
JUMP_INDEX: Subscript into JUMP_TABLE, which keeps the address where
the ACregisters 16B and 17B (stack frame boundaries)
are saved on entry. Used for GOTOs out of block.
EXIT_JUMP: True if this label is the subject of a GOTO out of block.
GOTO_CHAIN: Top of the chain of references to this label. See
explanation on chains above.
LABEL_ADDRESS: The address in memory where a GOTO to this label should
jump to.

THE DISPLAY ARRAY:

The array variable DISPLAY is the mechanism that implements the scoping rules
of PASCAL: The most important component of each of its elements is the CTP
FNAME which points to the IDENTIFIER descriptor of the first name that was
declared in that scope. The rest of them hang from it in a binary search tree.
While parsing the declaration of a record type, and when inside a WITH state-
ment, the chain of fields of that record hang from one of the elements of
DISPLAY. The index in DISPLAY matches exactly the scope level for all other
cases. DISPLAY[0].FNAME points to the binary tree of predefined objects, and
so on. When the parsing of the body of a procedure is finished, the whole
binary tree that describes it is thrown away. The descriptors of its parameters
are still around, though, hanging from the NEXT field.

BIBLIOGRAPHY AND ADDRESSING INFORMATION:

[2] Rodriguez, Armando: Linkage conventions of the Pascal compier,
for DEC-System10 and DEC-System20, Hamburg and Lots versions.
Available on-line at LOTS and SCORE in DOC:PASCAL.DOC;
Accessible at SU-AI by .READ PASNOT/5p

The documents described above, and this one, are part of the documenta-
tion included in the distribution package of PASCAL/PASSGO,
LOTS version.

This document is accessible at SU-AI by .READ PASNOT/6p, It is available
on-line at LOTS and SCORE in DOC:PASCAL.DOC.

Armando R. Rodriguez
Computer Science Departament
Stanford University
Stanford, Ca 94305
U.S.A.

P.O. Box 5771
Stanford, Ca 94305
U.S.A.

(415)497-4971
ARR@SU-AI, CSL.ARMANDO@SCORE
A.ARMANDO@LOTS

∂10-jul-79 1628 ARR Packing Policy

PACKING POLICY OF THE PASCAL AND PASSGO COMPILERS FOR DECSystem-10
AND DECSystem-20, LOTS AND HAMBURG VERSIONS.

Armando R. Rodriguez.
10-jul-79

INTRODUCTION:

The standard only says that the use of the reserved word PACKED in a type defi-
nition is an indication to the compiler that it should use a packing mechanism,
But it does not define the mechanism, an it implies that one way of doing it is
by doing nothing. PASCAL/PASSGO do have a mechanism, that tries to provide both
a reasonable packed space and the least possible loss in addressing efficiency,
by preventing potentially large (one-word long or more) objects from getting
aligned to a bit address, and by taking advantage of the half-word addressing
mechanism of the DEC-10 hardware.

POLICY:

The order of definition of this rules is intended for clarity only. It does
not imply any precedence rule. The rules should be mutually exclusive. If
there is any ambiguity, it is a bug in this document: Please tell ARR.

1. Every new variable is aligned at a new word boundary.

2. Every array or record, even if it is an element of a packed array or a field
of a packed record, is aligned at a new word boundary and has a size
given in full words, regerdless of whether it itself is packed.

4. Packed Files of ASCII or of a subrange of ASCII (e.g., CHAR) are actually
accessed at byte boundaries. PACKED has no effect on files of any other
type, that is, GETs and PUTs will move around full words.

5. In fields of records and elements of arrays, except for the previous rules:
A. Pointers are kept in half a word.
C. When the size of an object is larger than what is left of this word,
the object is aligned to the next word.
D. When the type of an object is a subrange of integer, but its lower bound
is negative, its size is a full word, and it is alligned to the next
word boundary.
E. All other cases are packed to the exact number of bits that they need,
and alligned in the next available bit. (boolean uses 1 bit, ASCII and
its subranges, 1 byte, that is, 7 bits).

THINGS THAT YOU CAN DO:

There are things that the compiler will not do, that you can do fairly easily,
by using the appropriate dummy fields to force an alignment that would give
you better addressing at runtime:

A. When the size of an object is exactly half a word (18 bits), the compiler
will not do anything special, but if it also happens to be aligned at
a half-word boundary, half-word addressing and moving will be used.

B. When you need the elements of one record to map all into one only word,
you have to do two things: (a) (obviously) make sure that the total
sum of the bit space needed is 36 or less, and (b) make sure that none
of the types of the fields is an array or record: even if it is packed,
it will alocate a full word for itself, and align at a new word boun-
dary.
EXAMPLES:

1. The next record fits in exactly one word: (36 bits) (thanks to DH)

VAR
A: packed record
a1: 0..63; (* will be 6 bits *)
a2: 31..33; (* also 6 bits *)
a3: 4094..4095; (* 12 bits *)
a4: ' '..'9'; (* 7 bits *)
a5: 0..31; (* 5 bits. *)
end;

2. some combinations of types:

TYPE
a = packed array[1..10] of boolean; (*1 word*)
b = array[1..10] of boolean; (*10 words*)
c = packed array[1..10,1..10] of boolean; (*10 words*)
d = packed array[1..10] of a; (*10 words*)
e = packed array[1..10] of b; (*100 words*)
f = packed array[1..10] of array[1..10] of boolean; (*100 words*)

∂20-jul-79 1433 ARR List of Error messages

The number is the index that the compiler knows the error by.

151 : ":" EXPECTED
152 : ")" EXPECTED
153 : "(" EXPECTED
154 : "[" EXPECTED
155 : "]" EXPECTED
156 : ";" EXPECTED
157 : "=" EXPECTED
158 : "," EXPECTED
159 : ":=" EXPECTED
160 : "OF" EXPECTED
161 : "DO" EXPECTED
162 : "IF" EXPECTED
163 : "END" EXPECTED
164 : "THEN" EXPECTED
165 : "EXIT" EXPECTED
166 : ILLEGAL SYMBOL
167 : NO SIGN ALLOWED
168 : NUMBER EXPECTED
169 : NOT IMPLEMENTED
170 : ERROR IN TYPE
171 : COMPILER ERROR
172 : DEVICE EXPECTED
173 : ERROR IN FACTOR
174 : TOO MANY DIGITS

201 : "BEGIN" EXPECTED
202 : "UNTIL" EXPECTED
203 : ERROR IN OPTIONS
204 : CONSTANT TOO LARGE
205 : DIGIT MUST FOLLOW
206 : EXPONENT TOO LARGE
207 : CONSTANT EXPECTED
208 : SIMPLE TYPE EXPECTED
209 : IDENTIFIER EXPECTED
210 : REALTYPE NOT ALLOWED
211 : MULTIDEFINED LABEL
212 : FILENAME EXPECTED
213 : SET TYPE EXPECTED
214 : UNDEFINED LABEL
215 : UNDECLARED LABEL

251 : "TO"/"DOWNTO" EXPECTED
252 : 8 OR 9 IN OCTAL NUMBER
253 : IDENTIFIER NOT DECLARED
254 : FILE NOT ALLOWED HERE
255 : INTEGER CONSTANT EXPECTED
256 : ERROR IN PARAMETERLIST
257 : ALREADY FORWARD DECLARED
258 : THIS FORMAT FOR REAL ONLY
259 : VARIANTTYPE MUST BE ARRAY
260 : TYPE CONFLICT OF OPERANDS
261 : MULTIDEFINED CASE LABEL
262 : FOR INTEGER ONLY "O"/"H"
263 : ARRAY INDEX OUT OF BOUNDS
264 : MISSING FILE DECLARATION
265 : LABEL CONSTANT TOO GREAT
266 : LABEL ALREADY DECLARED
267 : END OF PROGRAM NOT FOUND
268 : MORE THAN 72 SET ELEMENTS

301 : STRING CONSTANT IS TOO LONG
302 : IDENTIFIER ALREADY DECLARED
303 : SUBRANGE BOUNDS MUST BE SCALAR
304 : INCOMPATIBLE SUBRANGE TYPES
305 : INCOMPATIBLE WITH TAGFIELDTYPE
306 : INDEX TYPE MAY NOT BE INTEGER
307 : TYPE OF VARIABLE IS NOT ARRAY
308 : TYPE OF VARIABLE IS NOT RECORD
309 : NO SUCH FIELD IN THIS RECORD
310 : EXPRESSION TOO COMPLICATED
311 : ILLEGAL TYPE OF OPERAND(S)
312 : TESTS ON EQUALITY ALLOWED ONLY
313 : STRICT INCLUSION NOT ALLOWED
314 : FILE COMPARISON NOT ALLOWED
315 : ILLEGAL TYPE OF EXPRESSION
316 : VALUE OF CASE LABEL TOO LARGE
317 : TOO MANY NESTED WITHSTATEMENTS
318 : INVALID OR NO PROGRAM HEADING
319 : TOO MANY LABEL DECLARATIONS
320 : INCOMPATIBLE FORMALPARAMETER
321 : STRING PACKAGE IS DISABLED

351 : STRING CONSTANT CONTAINS "<CR><LF>"
352 : LABEL NOT DECLARED ON THIS LEVEL
353 : CALL NOT ALLOWED IN EXTERN PROGRAMS
354 : MORE THAN 12 FILES DECLARED BY USER
355 : FILE AS VALUE PARAMETER NOT ALLOWED
356 : TOO MUCH CODE: USE OPTION CODESIZE
357 : NO PACKED STRUCTURE ALLOWED HERE
358 : VARIANT MUST BELONG TO TAGFIELDTYPE
359 : TYPE OF OPERAND(S) MUST BE BOOLEAN
360 : SET ELEMENT TYPES NOT COMPATIBLE
361 : ASSIGNMENT TO FILES NOT ALLOWED
362 : TOO MANY LABELS IN THIS PROCEDURE
363 : INITPROCEDURE NOT ALLOWED HERE
364 : CONTROL VARIABLE MAY NOT BE FORMAL
365 : ILLEGAL TYPE OF FOR-CONTROLVARIABLE
366 : ONLY PACKED FILE OF CHAR ALLOWED
367 : CONSTANT NOT IN BOUNDS OF SUBRANGE

401 : IDENTIFIER IS NOT OF APPROPRIATE CLASS
402 : TAGFIELD TYPE MUST BE SCALAR OR SUBRANGE
403 : INDEX TYPE MUST BE SCALAR OR SUBRANGE
404 : TOO MANY NESTED SCOPES OF IDENTIFIERS
405 : POINTER FORWARD REFERENCE UNSATISFIED
406 :
407 : TYPE OF VARIABLE MUST BE FILE OR POINTER
408 : MISSING CORRESPONDING VARIANTDECLARATION
409 : MORE THAN 6 VARIANTS IN CALL OF "NEW"
410 : MORE THAN FOUR ERRORS IN THIS SOURCELINE
411 : NO INITIALISATION ON RECORDS OR FILES
412 : PROGRAM TOO BIG FOR PASSGO. USE PASCAL
413 : MORE THAN 100 INITPROCEDURES. USE PASCAL

451 : LOW BOUND MAY NOT BE GREATER THAN HIGH BOUND
452 : IDENTIFIER OR "CASE" EXPECTED IN FIELDLIST
453 : TOO MANY NESTED PROCEDURES AND/OR FUNCTIONS
454 : FILE DECLARATION IN PROCEDURES NOT ALLOWED
455 : MISSING RESULT TYPE IN FUNCTION DECLARATION
456 : ASSIGNMENT TO FORMAL FUNCTION IS NOT ALLOWED
457 : INDEX TYPE IS NOT COMPATIBLE WITH DECLARATION
458 : ERROR IN TYPE OF STANDARD PROCEDURE PARAMETER
459 : ERROR IN TYPE OF STANDARD FUNCTION PARAMETER
460 : REAL AND STRING TAGFIELDS NOT IMPLEMENTED
461 : SET ELEMENT TYPE MUST BE SCALAR OR SUBRANGE
462 : ONLY ASSIGNMENTS ALLOWED IN INITPROCEDURES
463 : NO CONSTANT OR EXPRESSION FOR VAR ARGUMENT
464 : EXTERN DECLARATION NOT ALLOWED IN PROCEDURES
465 : BODY OF FORWARD DECLARED PROCEDURE MISSING
466 : DOUBLE FILE SPECIFICATION IN PROGRAM HEADING
467 : TOO MUCH CODE FOR DEBUG: TRY MORE "CODESIZE"
468 : NO FORMAL-PROC/FUNC IN FORTRAN-SUBROUTINE
469 : THIS VAR ARGUMENT HAS TO BE OF TYPE STRING
470 : GLOBAL VARIABLES REQUIRE TOO MUCH MEMORYSPACE

501 : TOO MANY FORWARD REFERENCES OF PROCEDURE ENTRIES
502 : ASSIGNMENT TO STANDARD FUNCTION IS NOT ALLOWED
503 : PARAMETER TYPE DOES NOT AGREE WITH DECLARATION
504 : INITIALISATION ONLY BY ASSIGNMENT OF CONSTANTS
505 : LABEL TYPE INCOMPATIBLE WITH SELECTING EXPRESSION
506 : PREV. STATEMENT MISSING ";","END","ELSE"OR"UNTIL"
507 : NOT ALLOWED IN INITPROCEDURES (PACKED STRUCTURE?)
508 : GOTO INTO MAIN PROGRAM NOT ALLOWED IF "EXTERN"
509 : ASSIGNMENT TO FUNCTION NOT ALLOWED ON THIS LEVEL
510 : NO STD- OR FORTRAN-PROC/FUNC AS ACTUAL-PROC/FUNC

551 : FUNCTION RESULT TYPE MUST BE SCALAR,SUBRANGE OR POINTER
552 : REPETITION OF RESULT TYPE NOT ALLOWED IF FORW. DECL.
553 : REPETITION OF PARAMETER LIST NOT ALLOWED IF FORW. DECL.
554 : NUMBER OF PARAMETERS DOES NOT AGREE WITH DECLARATION
555 : RESULT TYPE OF PARAMETER-FUNC DOES NOT AGREE WITH DECL.
556 : SELECTED EXPRESSION MUST HAVE TYPE OF CONTROL VARIABLE
557 : TOO MANY FILES OR TOO BIG FILE ELEMENTS. USE PASCAL.
558 : ALREADY DECLARED. PREVIOUS DECLARATION WAS NOT FORWARD